The new generation mobile devices, such as smart phones, provide enhanced computational functionalities via open network connections. Such mobile devices are e.g. capable of receiving e-mail, sharing software with one another through short-range connections, downloading and executing software from the Internet, making automated calls and acting under remote control. Hence, similar to a personal computer, mobile devices and in particular the software components involved in the setting up of a connection between the mobile device to the network, are vulnerable to attacks of malicious code (malware). Typically malware attempts to make misuse of a mobile device or to simply disrupt legitimate use of a mobile device. A chip card that is possibly present on the mobile device, e.g. a (U)SIM, does not provide protection against this vulnerability.
One type of malware is referred to as dialers. Dialers are pieces of malicious code capable of illegally setting up calls on the infected mobile device. Such dialers often use authentication information from the (U)SIM of the mobile device to obtain access to the network as if the connection is legitimately set up by the mobile user. After the authentication procedure, the dialer starts to set up calls to e.g. expensive premium numbers—often not detectable for the user of the infected mobile device—leading to substantial financial risks for both the mobile user and the mobile operator.
Measures may be taken to eliminate or at least reduce the undesired effects of such malware. One known measure is the introduction of a filter in the network. Such filters are described in WO2007/041157 and US2005/0060399. A filter residing in a base station monitors calls transmitted from a mobile device and blocks calls which are listed on a blacklist. The network operator and/or mobile user may add service requests to the blacklist which should be explicitly excluded by the filter.
One problem relating to the use of such a filter is the management of the list of excluded service requests. On the operator side there are three problems. The first is that to block all undesired service requests, the size of the necessary blacklist can become very large and nearly unmanageable. The second problem is that a constant search for malicious services is necessary to keep the blacklist up-to date. The third problem is that the identification of suspicious requests requires analyses of the service requests of each individual mobile device user. Such analyses thus require substantial resources in the network. On the mobile user side, one problem resides in the fact that unwanted service requests of the mobile device are usually unnoticed by the user and only detected after billing, i.e. after the damage has already been realized. Another problem for the user may arise from the operator blacklisting services that the user does want to use.
US2008/0196099 discloses a method of filtering URLs (Uniform Resource Locators) inside IM (Instant Messaging) applications. In case an IM message contains a URL, this URL is checked against a blacklist of known malicious URLs. When the URL is not on the blacklist the sender is presented a challenge to confirm that the sender is an actual user and not a program (malware). This method protects recipients from receiving IM messages with malicious URLs. Furthermore the system can be configured to maintain an “allow list” or “white list” of known non-malicious URLs. This way an IM message containing a URL from the “white list” can be forwarded to the recipient without challenging the sender.
This method is undesirable from both the security point of view and the customer point of view when it is applied in the mobile phone context. From a security perspective the method of US2008/0196099 offers no solution for the problem at hand since not the content of communication forms a threat but the destination of the communication, e.g. premium numbers for calls or text messages (SMS). Therefore the described method tries to protect the recipient and not the sender. This method also forms a nuisance for the sender since the sender will be challenged for every IM message containing a URL which is not in the blacklist (or whitelist). When the sender (successfully) replies to the challenge the IM message including the URL will be forwarded but the whitelist is not updated based on the sender's action. This means that the sender will be presented a challenge for the same URL over and over again.
Summarizing the problems in the prior art:                the size of the blacklist may become unmanageable because all suspicious services must be put in the blacklist;        there is not an automatic build-up of whitelists;        the malware detection does not include a test on the particular service;        there is no rejection of service requests to new malicious destinations therefore a constant effort for the network operator or user to keep the blacklist up-to-date is needed;        the user is bothered multiple times when carrying out identical service requests;        there is the possibility that a network operator blacklists services that a user does want to use.        
Hence, there is a need in the art for a simple method of managing undesired service requests effectively and preventing misuse.